This repository has been archived by the owner on May 3, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This builds on top of #242.
One of the bigger challenges for shipper users is to decide if a rollout
is waiting for the right bits to be flipped up in the kubernetes cloud,
or if something went wrong with no hope of being fixed without
intervention. Although this commit does not fundamentally fix that (as
it would be very involved and error prone, requiring the capacity
controller to have intimate details of replica sets and pods, which we
want to avoid), we're now checking for a few more conditions in the
Deployment that surface known situations:
A Deployment has just been changed, and its Status does not reflect
the brand new Spec. In that case, we considered capacity to be just in
progress.
A Deployment times out. This is not super common, as it requires users
to define a timeout in the Deployment itself. If that ever happens,
though, we're covered :)
A Deployment would violate quotas, or would otherwise cause the
ReplicaSet to be in a state of error. That's insanely common, and also
super hard to diagnose without knowing that this is an error condition
to begin with.